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The  TEMPO  simulation  model  was  developed  for  analytical  support  to  Headquarters  Australian  Theatre 
(HQAST).  TEMPO  provides  the  analyst  with  a  tool  to  rapidly  compare  various  concepts  of  operation  for 
evacuation  and  other  movement  operations.  It  allows  modelling  of  deployment,  redeployment,  sustainment 
and  transportation  operations,  and  allows  the  analyst  to  investigate  alternate  “what  if’  cases  that  vary  from  a 
base  scenario.  Scenario  variations  can  be  prepared  and  analysed  on  a  time-scale  of  minutes  or  hours  to  aid  in 
operational  planning.  This  paper  provides  an  overview  of  the  TEMPO  model,  and  describes  how  it  meets  the 
analysis  requirements  for  the  Theatre  Planning  Group  at  HQAST,  using  a  scenario  based  on  the  evacuation 
from  East  Timor  in  September  1999  as  an  example. 


1.  HQAST  Theatre  Planning  Group  analysis  requirements 

Headquarters  Australian  Theatre  (HQAST)  is  responsible  for  planning,  conducting  and  supporting  Australian 
Defence  Force  (ADF)  campaigns  and  operations  at  the  theatre  or  operational  level.  HQAST  is  composed  of 
branches,  which  are  identified  using  the  United  States/NATO  standard  “J-designator”  system.  For  example, 
planning  branch  is  referred  to  as  J5;  this  branch  is  responsible  for  planning  of  future  ADF  operations. 

Within  the  context  of  theatre  planning,  any  analysis  carried  out  on  behalf  of  the  theatre  planners  must 
address  the  following  factors  as  best  as  possible1: 

•  Timeliness  -  Simulations  and  analyses  utilised  to  evaluate  a  concept  of  operations  must  be  developed, 
executed,  analysed  and  have  the  results  presented  within  a  near-real  timeframe  of  hours  to,  at  most,  days. 
Although  there  is  some  limited  opportunity  to  gather  data  ahead  of  time,  most  of  the  analytical  work 
must  be  achieved  within  the  timeframe  of  theatre  planning  meetings. 

•  Accuracy  and  Transparency  of  Results  -  The  principles  underpinning  the  analyses  must  be  specified 
explicitly,  with  any  data  used  verified  and  validated  as  far  as  possible  against  that  used  elsewhere  in  the 
courses  of  action  analysis  process.  Any  information  gaps  would  also  need  to  be  stated  unambiguously,  so 
that  the  results  could  be  interpreted  appropriately  in  context. 

•  Relevance  -  The  simulation  must  be  able  to  model  and  display  results  at  an  appropriate  level  of  detail. 
Results  should  not  only  provide  relevant  performance  measures,  but  it  is  also  important  that  they  be 
presented  in  a  concise  fashion  that  is  compatible  and  comparable  with  the  findings  of  other  planners. 

•  Relative  ease  of  generation  and  modification  -  The  system  used  for  analysis  should  be  reasonably 
simple  for  the  analyst  to  operate  and  maintain.  If  military  planners  are  not  directly  involved  with  the 
generation,  execution,  analysis  and  presentation  of  results  of  the  simulation,  this  obviates  the  need  for 
extensive  training,  documentation  and  service  support.  Analytical  results  are  typically  obtained  from 
several  different  simulation  runs.  It  follows  that  these  runs  should  be  appropriately  named  and  identified, 
so  that  the  appropriate  run  can  be  quickly  located  should  subsequent  analysis  and  modification  be 
required.  The  importance  of  appropriate  identification  of  analysis  results  is  further  increased  by  the  tight 
time  constraints  on  the  planning  sessions. 

With  these  requirements  in  mind,  five  different  approaches  were  considered  for  the  provision  of  analytical 
support  to  HQAST2: 
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1 .  Analytical  support 

•  Mathematical  models,  pencil  and  paper,  Expert  judgement. 

2.  Planning  support 

•  Visualization  tools,  visual  aids 

3 .  Calculator  models 

•  Outputs  provided  as  a  relatively  simple  function  of  input  values. 

4.  Optimization  models 

•  Linear  programming  and  related  approaches. 

5 .  Simulation  models 

•  Time  stepped  or  Event  stepped.  Geographical,  Network  or  Process  modelling. 

Each  of  these  techniques  has  advantages  and  drawbacks  as  far  as  fulfilling  the  criteria  mentioned  above  and 
need  not  be  implemented  in  isolation.  The  criterion  for  timely  information,  for  instance,  leads  to  a  need  to 
keep  the  data  requirements  for  any  tool  developed  to  be  relatively  simple.  However,  this  must  be  tempered 
with  the  need  for  useful  information  across  a  broad  theatre  level  operation.  This  leads  to  two  types  of  data 
requirement  with  different  timescales: 

1 .  Background  Information  (scenario  specific  -  not  part  of  the  plan) 

2.  Plan  Specific  Information 

Furthermore,  output  to  standard  briefing  format  should  occur  automatically  allowing  timely  presentation  of 
analytical  results.  Other  aspects  that  affect  the  modelling  approach  include  the  level  of  aggregation  and  the 
importance  placed  on  providing  a  theatre-level  overview  of  a  complete  operation.  A  simulation  modelling 
approach  is  particularly  good  for  this  because  it  can  be  used  to  check  the  integrity  of  a  complete  plan  in 
regards  to  movement  in  time  and  space. 

In  December  1999,  DSTO  scientists  began  developing  a  geographically  based  computer  simulation  to 
analyse  and  investigate  Evacuation  Operations.  This  software  comprises  two  fundamental  components: 

1.  Theatre  Operations  Modelling  Environment  (TOME),  a  set  of  JAVA  classes  that  incorporates 
simulation  functions  and  the  display  of  geographical  information  in  a  Graphical  User  interface 
format. 

2.  Theatre  Evacuation,  Movements  and  Peace  Operations  (TEMPO),  an  additional  set  of  JAVA  classes 
that  are  used  to  model  the  movement  of  assets  from  one  location  to  another,  and  to  read  input  from  a 
Microsoft  Access  database  which  holds  scenario-specific  information. 

TOME  was  developed  to  provide  general  geographically  based  simulation  functionality.  TEMPO  contains 
higher-level  algorithms  that  are  specifically  geared  towards  modelling  evacuation  and  movement  operations 
and  relies  upon  the  underlying  TOME  functionality.  Initially,  the  TEMPO  simulation  was  demonstrated  to 
J5AST,  using  historical  recreations  of  the  evacuation  of  Australian  and  Approved  Foreign  Nationals  from 
East  Timor  by  the  ADF  in  September  1999.  Following  positive  comments  from  military  planners,  further 
extensions  and  improvements  were  included,  and  the  software  continues  to  be  developed. 


2.  The  TEMPO  simulation  model 

One  of  the  key  modelling  philosophies  behind  the  design  of  TEMPO  was  an  emphasis  on  the  transparency  of 
model  results.  An  integral  part  of  this  philosophy  was  the  desire  to  reduce  the  amount  of  model  behaviour 
that  was  hard- wired  into  the  code  and  hence  hidden.  Instead  the  model  has  been  structured  in  a  strongly  data- 
centric  manner.  This  data-driven  approach  to  modelling  allows  the  behaviour  of  the  model  (such  as  the 
standard  operating  practice)  to  be  database-driven  with  the  model  logic  defined,  in  the  main,  by  the  analyst  in 
a  scenario  specific  way.  This  provides  for  a  great  deal  of  flexibility  as  well  as  transparency  in  the  model’s 
behaviour. 


A  second  element  of  the  design  philosophy  that  runs  somewhat  counter  to  this  is  the  need  to  keep  the  data 
requirements  relatively  simple,  in  line  with  its  theatre-level  perspective.  These  two  objectives  have  been 
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achieved  in  TEMPO  using  an  object-oriented  framework.  Basic  classes  describing  assets,  operational 
parameters,  road  networks,  transports  and  crews  are  provided  by  the  model.  These  have  certain  basic  data 
requirements.  It  is  up  to  the  user,  however,  to  define  through  the  database  particular  objects  (e.g.  particular 
transports,  or  particular  assets  of  interest)  to  be  used  in  the  model  and  how  these  should  behave.  The  analyst 
is  thereby  free  to  identify  key  drivers  for  a  particular  scenario  and  to  use  the  model  to  track  the  assets, 
parameters  or  other  items  which  are  relevant  to  these  drivers.  Furthermore  the  aggregation  used  by  the  model 
can  be  fully  defined  by  the  analyst  along  with  the  model  logic  which  specifies  the  behaviour  of  these 
aggregations. 

The  data  requirements  of  TEMPO  can  broadly  be  separated  into  three  distinct  categories.  These  are: 

1.  Geographical  data  -  data  which  defines  the  map  layers,  key  locations  in  the  scenario  and  the  route 
network  connecting  these. 

2.  Force  Element  data  -  data  which  defines  the  specific  transports,  crew,  assets  and  operational  parameters 
available  and  key  parameters  relating  to  the  performance  of  these  items. 

3.  Scenario  Concept  of  Operation  -  data  which  defines  the  concept  of  operation  under  consideration.  This 
includes  user-specified  orders  or  requests  with  triggering  conditions  and  priority  levels.  It  may  also 
define  operational  requirements  and  restrictions  on  items  defined  in  the  force  element  data  (such  as 
consumption  rates,  resource  availability  and  time  restrictions). 

A  brief  description  of  each  data  category  follows;  more  details  may  be  found  in  reference  [3]. 

Geographical  data  is  displayed  in  TEMPO  with  a  map  display  based  on  the  freeware  OpenMap  package,  a 
simple  GIS.  Multiple  layers  can  be  displayed,  including  maps  in  ESRI  shape  file  format,  Digital  Terrain 
Elevation  Data  (DTED),  day/night  shading,  and  icons  representing  user-defined  simulation  objects  such  as 
ships  and  aircraft.  The  display  allows  the  various  layers  to  be  turned  on  and  off,  or  moved  to  the  foreground 
or  background.  The  map  scale  and  projection  can  also  be  changed  as  required. 


Figure  1:  TEMPO  display,  with  day/night  shading  and  the  map  displayed  at  large  scale  in 
orthographic  projection. 
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The  simulation  uses  a  node  and  arc  network,  which  must  be  defined  in  the  Access  database  for  each  scenario. 
The  node  coordinates  are  specified  as  latitudes  and  longitudes,  and  the  arcs  are  specified  as  linking  any  two 
named  nodes. 


2.1  Force  Element  Data 

In  a  given  scenario  there  is  a  requirement  for  the  force  elements  and  assets  available  to  be  defined.  Much  of 
this  data  remains  static,  however,  and  can  be  reused  in  different  analysis  scenarios.  The  data  required  for 
TEMPO  includes 

1.  Transports 

2.  Crew 

3.  Assets 

4.  Parameters 

2.1.1  Transports 

Transports  can  be  defined  either  individually,  or  grouped  collectively  with  a  common  name.  The  basic 
parameters  that  define  and  identify  a  transport  include  its  name,  speed,  range,  pax,  operational  capacity, 
initial  ready  time  and  turn-around  time.  Transports  also  have  a  priority  value  which  gives  the  minimum 
priority  tasks  that  that  transport  is  available  for.  If  a  request  is  placed  with  a  lower  priority  the  transport  may 
be  held  as  unavailable. 

Other  items  which  given  transports  can  carry  can  also  be  added,  so  that  each  transport  has  a  fixed  maximum 
and  minimum  carrying  capacity,  as  well  as  consumption  (or  production)  rates  of  any  number  of  items.  Thus, 
the  database  allows  the  user  to  define  any  number  of  assets  or  parameters  that  a  transport  may  carry  or  have 
associated  with  it  (for  example  the  asset,  “fuel”,  or  the  parameter,  “service  level”).  Transports  may  be 
defined  as  requiring  a  crew  to  move,  in  which  case  the  crews  that  are  able  to  drive  the  transport  must  be 
defined  in  turn.  Transports  may  also  be  given  operational  restrictions,  such  as  a  restriction  that  it  is  unable  to 
work  during  certain  hours  of  the  day  (e.g.  night  time  flying  restrictions  on  a  helicopter)  or  other  restrictions 
on  total  time  in  use. 

2.1.2  Crew 

Crew,  like  transports,  are  defined  either  individually  or  grouped.  Crew  may  represent  within  TEMPO  a 
particular  crew  or  crew-type  required  to  work  a  transport.  The  transport  or  set  of  transports  that  a  crew  is 
able  to  run  is  defined  in  the  database.  Alternatively  a  crew  may  not  specifically  drive  a  transport,  but  may 
represent  a  force  element  such  as  a  medical  crew  or  even  combat  forces.  As  for  transports,  crews  have  an 
operational  capacity,  initial  ready  time,  re-ready  time,  and  a  minimum  priority  of  the  tasks  on  which  that 
particular  crew  is  available  to  work. 

Crew  may  also  have  working  restrictions  placed  upon  them.  These  may  include  a  maximum  number  of  hours 
they  are  available  to  work  per  day,  or  a  maximum  number  of  days  available  per  week.  Alternatively, 
restrictions  relating  to  unavailability  during  particular  hours  of  the  day  (e.g.  unavailable  at  night)  can  be 
enforced. 

2.1.3  Assets 

Within  TEMPO,  crew  and  transports  are  particular  specialised  assets  that  carry  with  them  specialized 
properties  and  behaviour  discussed  above  (e.g.  maximum  range,  speed  or  operational  restrictions  on 
transports  along  with  the  ability  to  be  used  in  moving  between  locations  if  requested).  They  also  have  fixed 
relations  to  other  aspects  of  the  model,  for  instance  a  crew  may  be  required  to  run  a  transport. 
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The  analyst  is  also  able  to  define  any  number  of  additional  assets  within  TEMPO  for  use  in  a  particular 
scenario.  An  asset  is  normally  used  to  describe  a  physical  quantity  within  the  model.  Typical  examples 
would  be  “fuel”,  “food”  or  “evacuees”.  Each  asset  is  stored  in  a  conceptual  “bucket”  at  each  place  it  is  being 
used  or  carried.  Valid  places  where  asset  “buckets”  may  be  located  include  physical  locations  (e.g.  fuel  at 
Dili),  transports  (e.g.  AVTUR  at  Cl 30)  and  crew  (e.g.  food  at  Jervis  crew).  The  bucket  that  holds  an  asset 
has  properties  such  as  the  minimum  amount  and  maximum  amount  of  the  asset  that  can  be  held.  They  may 
also  be  to  be  “leaky”  -  meaning  that  the  asset  stored  in  this  “bucket”  has  an  intrinsic  rate  of  consumption  (or 
production)  per  unit  time  or  per  unit  motion.  For  instance  fuel  on  a  Cl 30  may  have  a  particular  rate  of 
consumption  per  unit  motion,  a  minimum  value  of  zero  and  a  maximum  value  equal  to  the  fuel  capacity  of 
the  aircraft.  Other  asset  reserves  at  a  fixed  location  may  have  a  rate  of  consumption  or  production  per  unit 
time  (rather  than  per  unit  motion),  allowing  the  analyst  to  avoid  detailed  modelling  of  a  particular  asset’s 
consumption  if  detailed  modelling  is  not  required.  Assets  also  have  a  minimum  priority  task  on  which  they 
may  be  used,  defined  by  the  user. 

Asset  sources  and  sinks  can  also  be  defined,  separate  from  the  asset  containers.  These  can  be  used  to 
represent  things  like  the  arrival  of  evacuees  at  an  assembly  area,  or  the  consumption  of  fuel  at  a  particular 
location.  The  rate  of  arrival  of  an  asset  at  a  source,  or  its  departure  at  a  sink,  may  be  changed  dynamically. 
For  example,  at  day  one  of  the  model  run  evacuees  begin  flowing  into  each  Evacuee  Assembly  Area  at  an 
initial  rate  of  10  per  hour,  increasing  over  the  course  of  a  week  up  to  20  per  hour. 

2.1.4  Parameters 

Within  TEMPO,  the  analyst  is  also  free  to  define  an  arbitrary  number  of  parameters  that  may  be  used  in  the 
model.  The  definition  and  behaviour  of  a  parameter  in  TEMPO  is  very  similar  to  an  asset,  however 
conceptually  these  are  somewhat  different.  While  an  asset  describes  a  physical  quantity  within  the  model,  a 
parameter  is  used  to  quantify  a  concept  within  the  scenario.  For  example  a  “threat”  parameter  may  be 
defined  at  each  of  a  series  of  locations  or  a  “morale”  parameter  may  be  defined  at  a  crew  or  transport. 

Apart  from  this  conceptual  difference,  however,  parameters  are  handled  in  a  way  that  is  almost  identical  to 
assets.  A  “bucket”  of  the  parameter  at  a  particular  location  defines  its  value,  along  with  its  maximum  and 
minimum  value  and  any  intrinsic  growth  or  decay  behaviour.  Parameter  sources  and  sinks  provide  the  user 
with  the  ability  to  control  the  changing  value  of  the  parameter. 

For  instance,  a  “threat”  parameter  may  be  defined  at  all  locations  in  East  Timor,  with  initial  values  of  threat 
in  all  locations  set  to  zero  and  a  maximum  value  of  one  hundred.  The  threat  may  then  be  slowly  increased  at 
all  locations  using  one  (or  more)  sources  of  threat  which  increase  the  threat  at  each  location  at  a  particular 
rate.  The  actual  effect  of  the  “threat”  parameter  must  then  be  defined  by  the  analyst.  This  is  achieved  by 
setting  up  orders  that  are  triggered  by  particular  threat  values. 


2.2  Scenario  Concept  of  Operation  Data 

The  final  data  required  by  TEMPO  is  the  data  that  defines  the  concept  of  operation  under  consideration. 
These  include  user-specified  orders  or  requests  with  triggering  conditions  and  priority  levels.  The  user  may 
also  define  operational  requirements  and  restrictions  on  items  defined  in  the  force  element  data. 

The  basic  mechanism  by  which  an  analyst  defines  the  progress  of  a  scenario  is  through  “requests”.  Each 
request  is  made  up  of  four  main  components  which  provide  the  flexibility  to  produce  a  wide  range  of 
behaviour  from  the  model: 

1 .  The  trigger  or  initiator  that  starts  (or  restarts)  the  request. 

2.  The  list  of  requested  items  involved  in  the  request.  These  may  be  a  single  unit  (such  as  a  transport),  or  a 
transport  may  be  requested  to  carry  one  or  more  additional  items  (such  as  evacuees).  At  its  most  general 
the  requested  items  may  involve  a  task  group  of  transports  of  different  kinds  with  various  assets,  crew, 
and  parameters  being  sent  or  travelling  with  each  transport. 
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3.  The  locations  the  request  is  to  occur  between.  These  may  be  specified  explicitly,  or  by  type,  region  or 
other  grouping.  Specific  paths  may  be  specified  if  required,  and  the  mechanism  of  travel  (i.e.  travel 
together  or  not)  may  also  be  set. 

4.  The  (possibly  dynamic)  priority  of  the  request,  and  any  alternate  requests  that  may  be  initiated  if  this 
request  can  not  be  met. 

Request  initiators  are  constructed  in  the  database  using  Boolean  logic.  For  instance,  suppose  we  wish  to 
move  evacuees  out  of  an  area  (i.e.  start  a  movement  request)  after  5  days  have  passed,  however  we  would 
start  this  movement  earlier  if  the  threat  is  greater  than  50  AND  the  number  of  evacuees  at  the  location  is 
greater  than  10.  The  initiator  for  this  request  would  be  expressed  as 

(Simulation  Time  >  5  days)  OR  ((Threat  >  50)  AND  (Number  of  Evacuees  >  10)) 

Items  and  locations  may  be  requested  in  a  general  way,  for  example  “any  air  transport”,  “any  two 
helicopters”,  “any  Evacuee  Assembly  Area”  etc.  Combined  with  the  Boolean  logic  in  the  request  initiator, 
this  gives  the  analyst  plenty  of  freedom  to  define  the  concept  of  operation  in  the  model.  The  construction  of 
requests  in  TEMPO  is  described  in  more  detail  in  reference  [3]. 

2.3  Data  Display 

TEMPO  allows  the  user  to  display  and  modify  parameters  for  a  large  number  of  the  objects  involved  in  a 
simulation  run.  These  allow  the  analyst  to  investigate  “what-if  ’  like  conditions  for  a  given  scenario  and 
change  values  during  a  simulation’s  progress.  The  list  of  data-displays  include  displays  for  fixed  items 
(Figure  2),  mobile  display  (Figure  3)  and  displays  relating  to  the  requested  items  and  initiators  (Figure  4). 
Displays  are  available  for  each  of  the  items  listed  below: 

•  Locations 

•  Transports 

•  Crew 

•  Assets  and  Asset  sources/sinks 

•  Operational  Parameters  and  Parameter  sources/sinks 

•  Requests 

•  Request  Items 

•  Initiators 

•  Mobile  objects 
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EU3 

Location  Information 

Time:  ^  day,  1 2:29:59.999 

Name:  Dm (ehc)  Crew  Information 

Number:  164  Time:  1  day.  1 2:29:59.999 

Position:  (-8.541699409484863.125.518  Na|m  BlackHawk  Crew  ID:  6 

OpOap:  |1.0| 

Transports:  Bj:  BLACKHAWK 


nernl 


| BLACKHAWK  Display 


Transport  Information 

Time:  1  day,  1 2:29:59.999 

Name:  BLACKHAWK  ID:  6 

Location:  ffitlBWB  imageName:  |BHelo1  gif 

Speed:  ||27a392  range:  |750.06(  Pa*  |20 

opCap:  fTo  minPriorityTasks:  [o'o 

[hours 


Asset  Information 

no  Ev  time:  1  day, 1 1^29:59.999 
NoEv  Name:  DIESCf  ID:  20 

netRe  unit  That  Controls:  |Dili  (1 64) 

value:  MUmum  minPriorityT 


_  minValue  JcuT 

-  Change: 


max’ 


Parameter  Information 


Time:  1  day,  1 2:29:59.999 

Name:  Threat 


Per  Unit  Time 


Unit  That  Controls:  |Dili  (1 64) 


EvacueesProcessed  Arrivals 


Arrivals  Information 

Time:  1  day,  12:29:59.999 

Arrival  No:  10  Asset  Name:  EvacueesProce... 


net  Produced:  0.0 
netTraded:  0.0 

Show  Asset  Data  Plot 


i -  Location: 

thresholds:  |[0. 0,20.0)  -  Nor 


“  (SET)  Initial  Pulse:  396.0 


minValue  |o.O 


mexValue:  |mo  Initial  Rate:  pF 


[TTT 


Final  Rate:  |o.o 

|days 


Show  Parameter  Data  Plot 


Time  Started:  |0.0 


unavailable  from:  0.0 


Time  Stopped:  |-1 .0 
to  Eo" 


Figure  2:  Some  of  the  fixed  information  displays  available  in  TEMPO. 

I-IdMI 


Mobile:  JeepEvacueeMovement  Display 


Mobile  Information 

Time:  ^  day,  12:29:59.999 
Mission  Priority:  |o"o 

Coming  from:  Unit  1 58  :  Ainaro  ( EAA ) 
Going  to:  Unit  1 64  :  Dili  (EHC) 

Time  started:  1  day,  1 2:06:23.842 

Transports: 

crew:  |23:  JeepCrew 
Expected  Mission  Lenth:  02:31 :59.880 
All  Objects:  | 

Request  No:  10 


3 


3 


Connectivity  Nos:  192- 

Connectivity  MinOpCap:  |T"o 


Assets:  |DIESO  (0.0) 
Params:  \~ 

WITHDRAWEL  ORDER 


T3 

"3 


Figure  3:  The  mobile  display  -  showing  a  request  in  action. 


Request  Item  62  Display 


Request  10  Display 


Request  Information 

Time:  1  day,  12:29:59.999 

ID:  IQ  Started  at:  NOT  CURRENTLY  RUNNING 

Initiator  Conditions:  |EvacueesProcessed  >=  I.OjANY)  Tl 

|[62]  JEEP 


Requested  Items: 


3 


Locationl :  | 
Location2:  T 
Connection  Path:  [ 
r  Travel  Together 
Initial  Priority:  |o.O 


|[1 58]  Ainaro  (EAA) 


~3 


|[1 601  Baucau  (EHC) 


31 


Image: 


W  Met  with  acceptable 


Ramp  Time:  ll.O 
Resource  Alternate:  |cT" 


Final  Priority:  |0.0 
Expire  Time:  fTo  [days- 


Destination  Alternate:  |0 
Comment:  [WITH D RAVVE L  ORDER 
Separate  Triggering:  [none 


~3 

~3 


Request  Item  Information 

Time:  1  day,  12:29:59.999 

Request:  |Request  1 0  (JeepEvacu...  | 

Name  of  Request  Items  Group:  |jeepEvacueeMovement 
Carried  By:  |ltself 

Item  Name:  |JEEP 


Item  ID:  W~ 


No  Wanted:  |#EvacueesProc  0.0 

No  Acceptable:  pj~o  0.0 

(NB:  Currently  ACCEPTABLE  Ok) 

Wait  Time:  ^ 

R  Send  For  Using:  \~ 

Other  Request  Items:  fl^ 


[hoi 


Initiator  Condition  14  Display 


rnsrnl 


Initiator  Condition  Information 

Time:  1  day,  12:29:59.91 
Condition  ID:  |l  4 


Name  of  Initiator: 
✓  Necessary? 
Modifier:  ”|[ANY  | 


Other  Initiator  Conditions:Hdays  >=  1 .0  (ANY) 


CheckValue  Current  Value:  FALSE 


Figure  4:  Some  displays  relating  to  requests 


Plotting  displays  are  also  available  to  present  data  in  a  graphical  form.  The  value  of  any  asset,  or  operational 
parameter  over  time  can  be  plotted.  For  instance,  in  the  case  of  the  evacuation  of  East  Timor,  we  may  wish  to 
investigate  the  number  of  Evacuees  at  a  particular  location  (say  Baucau)  as  a  function  of  time.  Figure  5 
shows  a  typical  plot  of  this  kind. 

Evacuee  Nos  at  Baucau 


Update  Plot  | 

Copy  for  PowerPoint 

Export  To  Excel 

Figure  5:  Plot  of  evacuee  numbers  at  Baucau 

These  plots  can  be  copied  to  Powerpoint,  or  the  data  exported  to  Excel  and  a  new  plot  generated  in  Excel. 
Other  data  collected  by  the  model  during  a  run  can  also  be  exported  to  Excel  for  further  analysis. 
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3.  East  Timor  evacuation  scenario 

Following  the  August  1999  independence  vote  in  East  Timor,  conditions  in  the  territory  rapidly  deteriorated, 
with  escalating  militia  violence  and  destruction.  The  Australian  Defence  Force  conducted  an  operation  to 
evacuate  Australian  and  other  foreign  nationals  from  East  Timor.  This  historical  scenario  was  used  to 
validate  the  TEMPO  simulation  model. 


Figure  6:  East  Timor  evacuation  scenario.  The  number  of  evacuees  at  each  location  is  shown; 
colours  indicate  different  levels  of  threat. 

The  East  Timor  evacuation  scenario  provides  a  simple  example  of  the  kind  of  analysis  that  may  be  supported 
with  the  use  of  TEMPO.  The  data  presented  here  is  fictitious  and  is  provided  for  demonstration  only. 

It  is  incumbent  upon  military  personnel  to  reduce  the  timeframe  of  an  evacuation  to  the  shortest  duration 
possible.  Extended  deployments  require  extensive  logistic  support  and  resupply,  thereby  greatly  increasing 
the  scale  of  the  operation.  If  a  larger  scale  operation  is  warranted,  then  the  associated  logistics  requirements 
increase  significantly,  and  must  be  factored  into  planning.  It  is  therefore  imperative  that  planners  have  a 
realistic  estimate  of  the  likely  duration  of  the  operation  as  early  as  possible  in  the  planning  process.  If 
analysis  indicates  that  the  interval  is  likely  to  be  prolonged,  then  further  planning  will  determine  what 
additional  resources  could  either  reduce  the  operation  to  an  acceptable  timeframe  in  the  best  case,  or 
logistically  to  support  the  deployed  force  beyond  its  normal  viable  period  of  operation  in  the  worst  case. 
Hence  the  main  MOE  for  the  East  Timor  scenario  is  the  time  taken  to  complete  the  evacuation. 

TEMPO  can  be  used  to  investigate  a  number  of  “what-ifs”  in  relation  to  the  base  scenario.  These  could 
include  issues  relating  to: 

•  Weather  effects  on  routes  and  transport  use 

•  Concurrent  operations 

•  Limited  logistics/resources 

•  Change  of  mode  of  evacuation  (eg  Air  vs  Sea) 

•  Effects  of  escalated  threat 
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The  basic  methodology  for  the  use  of  TEMPO  is  to  consider  a  number  of  alternate  scenarios,  such  as: 

1 .  Flow  interception  along  a  major  route  (cutting  the  bridge  at  Manatuto). 

2.  Evacuation  by  sea  rather  than  by  air. 

3.  Scenario  with  increased  population  to  be  removed  with  the  same  assets. 

Using  these  three  “what-ifs”  as  a  basis  we  then  investigate  the  effect  of  varying  key  parameters  for  each.  Our 
sample  conclusions  may  then  be  presented  with  plots  to  back  them  up.  For  example,  our  base  scenario  may 
take  about  eleven  days  to  complete  the  evacuation: 


In  these  plots  the  red  line  shows  the  number  of  people  evacuated  to  Darwin,  the  yellow  line  people  awaiting 
evacuation  in  East  Timor,  and  the  blue  line  evacuees  in  transit.  We  may  then  examine  alternate  scenarios  and 
draw  conclusions.  For  instance, 

❖  Provided  there  are  at  least  4  helicopters  at  Dili  and  ground  escorts  provided  locally,  the  loss  of  the  bridge 
at  Manatutu  does  not  lead  to  the  operation  exceeding  its  planned  duration: 


❖  However,  loss  of  available  security  crews  for  ground  escorts  (or  reducing  this  number)  may  have  a  large 
effect 


11 


TEMPO  is  also  designed  to  investigate  the  logistics  effect  of  various  operations.  For  instance,  we  may  find 
that  if  evacuation  by  shipping  is  required,  we  will  note  a  corresponding  requirement  for  greater  fuel  supplies 
at  Dili: 
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The  effect  of  changing  the  mode  of  evacuation  can  also  be  evaluated: 

GLOBAL  EVACUEES  STATS 


Time  [days] 

Update  Plot 

The  blue  line  indicates  the  number  of  people  in  transit  between  countries.  This  plot,  using  sea  evacuation, 
shows  a  correspondingly  longer  transit  time  than  for  the  case  of  air  evacuation. 

TEMPO  provides  a  flexible  tool  for  investigating  different  operational  concepts,  resource  availability  and 
other  constraints.  The  output  it  provides  is  in  the  form  of  plots  and  tables  of  resource  use  and  time  taken  to 
achieve  various  values.  In  this  case  we  are  considering  the  asset  “evacuees”  and  the  time  taken  to  move  this 
from  one  set  of  locations  (in  East  Timor)  to  another  set  (in  Australia).  In  another  scenario  the  key  MOE  and 
the  assets  and  parameters  considered  could  all  be  quite  different. 
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Presentation  Overview 


-  HQAST  -  Background  to  planning 

-  HQAST  Theatre  Planning  Group  analysis  requirements 

-  The  TEMPO  simulation  model 
East  Timor  evacuation  scenario 


DEFENCE 
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HQAST  Planning  -  Background 


Headquarters  Australian  Theatre  (HQAST) 
is  responsible  for  planning,  conducting 
and  supporting  joint  ADF  campaigns  and 
operations  at  theatre  level. 

Planning  of  future  ADF  operations  is  the 
responsibility  of  J5  branch,  achieved  by 
Theatre  Planning  Groups  (TPG)s. 


TPG 


TPGs  incorporate 

situational  review, 
scoping, 

development,  testing, 
modification  & 
refinement  of  the  CONOPS. 


Other 

ADF 


/ 


HQAST 
Branches  & 
Component 
Reps 


Other  Gov’t  Industry 


Other 

ADO 


NGO’s 
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Motivation  for  OR  Support 


Recent  high  priority  operations  related  to 
Evacuation  and  Peace  Support  Ops 
eg  East  Timor,  Solomon  Islands, 
Bougainville. 

In  the  projected  strategic  climate,  it  is  very 
likely  that  further  complex  and  possibly 
concurrent  operations  of  this  kind  will  be 
needed  in  the  future. 

Analysis  &  models  could  assist  with 
handling  complexity  &  concurrency,  and 
speed  up  the  development  of  efficient  and 
robust  deliberate  and  immediate  plans. 
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HQAST  TPG  Analysis  Reqmrements 

Timeliness  -  Some  support  available  in  hours/minutes.  In  depth 
analysis  on  timescale  of  days. 

Broad  level  of  aggregation  but  scaleable.  May  need  ability  to 
specify  (few)  particular  tactical  components. 

Provide  “big  picture”  overview  allowing 
interactions  to  be  considered  and  overall 
campaign  plans  to  be  evaluated. 

Ability  to  represent  and  effect 
changes  in  concept  of  operations 


SCIENCE &TECHNOLOGY 


HQAST  TPG  Analysis  Requirements  (ctd) 

Ability  to  make  doctrine  and  operating  assumptions  transparent 
and  user  specified. 

Ability  to  perform  sensitivity  analysis,  including  with  respect  to: 

-  concepts  of  operation 

-  resource  availability  and  effects  of  concurrency 

-  constraints  and  contingencies 

Provide  outputs  in  a  manner  that  is  compatible  with  TPG 
formatting 

Ability  to  include  some  degree  of  local  and/or  global  optimisation 
to  aid  in  analysis  advice. 
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Theatre  Evacuation,  Movement  &  Peace 
Operations  (TEMPO)  simulation  model 
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TEMPO:  Overview 


A  JAVA  simulation 
environment  for  modelling 
evacuation,  movement, 
deployment  and  transport 
operations. 

Developed  specifically  with 
simulation  and  analysis  of 
ADF  evacuation  operations 
in  mind. 

Strongly  data-driven  model  - 
scenario  parameters,  data 
and  logic  is  user-specified  in 
an  MS-Access  database. 


& 
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TEMPO:  TvDical  I 


Geographical  factors. 

-  Key  locations 

-  Routes  available,  plus  condition. 
Graphic  of  map/DTED  data. 


Force  Element  Data. 

-  Availability/  Prepositioning 

-  Operational  requirements 
e.g.  consumption  &  resource 
availability. 

-  Operational  restrictions 

e.g.  No-go  areas,  time  limits, 
crew  &  resource  limits, . . . 


uts 


Scenario  information. 


-  Threat  by  location/region. 

-  Evacuee  Numbers 
location/region. 

-  Resource  availability  & 
limitations  (e.g.  Fuel,  Water, 
other  assets  or  operational 
parameters). 


Concept  of  Operation  information. 


-  User  specified  orders 


-  Movement  priorities. 


-  Variations  in  CONOPS. 


Operational  Phases 
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TEMPO:  Typical  Outputs  (MOEs) 


Variation  of  key  operational  measures 
over  time  e.q. 

-  #  of  people  evacuated. 

-  #  of  people  remaining. 

-  #  of  sorties  required. 

Logistic  resource  usage  statistics: 

-  Fuel. 

-  Crew  hours. 

-  Aircraft  flying  hours. 

-  etc... 

Suggested  resource  allocation  e.g. 

-  Transport  assets. 


“What-if”  analysis 

compare  MOEs  for  scenario  variations  in: 

-  Mode  of  evacuation  (sea/land/air) 

-  #  of  evacuees  to  be  removed 

-  #  change  of  RC 

-  #  change  of  transport  assets 

-  Concurrent  operations 

-  Limited  logistics  support  resources 

-  Weather  effects  on  transport  &  routes 

-  User  specified  orders/priorities 


Data  export 

To  Excel  (For  more  analysis) 
To  Powerpoint  (For  briefing.) 
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TEMPO^SampJe  Screen  Shots 


AVTUR  Quantities  at  C130H 
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TEMPO:  CoJIected  statistics 

-  Can  investigate  the  progress  of  the  scenario: 

[^^Globa^tatistic^Displav 


GLOBAL  STATISTICS  AT  TIME:  1  week,  3  days,  17:00:00.00 


ID 

Location  Name 

No.  Evacuees 

Op  Cap  1 

Threat 

TOTAL  E/ 


NA 

TOTAL  EHC 

0.0 

1.0 

75.24999999999952 

NA 

TOTAL  RC 

963.0 

1.0 

44.2499999999997 

NA 

TOTAL  MOBILE 

NA 

ALL  IN  AUST 

963.0 

1.0 

44.2499999999997 

NA 

IN  OTHER  COUNTRY 

0.0 

1.0 

53.08333333333311 

NA 

TRANSIT 

-2 

HQ 

0 

1.0 

0.0 

1 

Dili 

0 

1.0 

79.2499999999995 

2 

Darwin 

963 

1.0 

44.2499999999997 

3 

Townsville 

0 

1.0 

44.2499999999997 

5 

Cairns 

0 

1.0 

44.2499999999997 

6 

Baucau 

0 

1.0 

71.24999999999953 

7 

Liquica 

0 

1.0 

100.0 

S 

Lautem 

0 

1.0 

30.249999999999936 

9 

Suai 

0 

1.0 

44.2499999999997 

10 

Aileu 

0 

1.0 

56.2499999999997 

11 

Ainaro 

0 

1.0 

79.2499999999995 

12 

Atsabe 

0 

1.0 

11.583333333333394 

Plot  Overall  Numbers 
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TEMPO:  Collected  statistics 

-  Compare  allocation  and  usage  of  resources 


j Resource  Use  Display 


RESOURCE  USE  INFO,  AT  TIME:  1  week 


:  30:  DO 


ID  (No  In  Type)  j  Transport...  %  Time  Mob...|  No.  Trips  . 


EBEBsBB 


TYPE  (1  TRANSPORTS) 


Air 


Ground 


Helo 


a 


JEEP 


3.36 

3.36 

3.36 

3.36 

56.9453456. 


50.6550354...  39 


57.492499 


0.0 


ays,  i 


Tot  No.  P...  Avg  %  Fu...  Avg  No  P 


963.0  44.0934...  40.1  2 


5.6710... 


0.71  428... 


6 

6 

6 

6 

0.0 


50.0 

50.0 

26.3736.. 


45.7894... 

39.375 

49.2307., 


45.0 


40.0 
~  NA 

"na . 
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East  Timor  evacuation  scenario 


Historical  scenario  used  to  validate  the  model 


Simulation  Time  :  1  day,  05:50:00.00  Standard  Mouse  Mode  STARTUP  PHASE 
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East  Timor  evacuation  scenario 


-  Principal  MOE  is  the  time  taken  to  complete  the 
evacuation. 

-  Basic  methodology  for  using  TEMPO  is  to  consider  a 
number  of  alternate  situations  -  for  example: 

•  Evacuation  by  sea  instead  of  by  air 

•  Shortage  of  escorts  for  ground  convoys 

•  Increased  number  of  evacuees 

-  The  effect  of  varying  key  parameters  is  investigated 
in  each  situation. 
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East  Timor  evacuation  scenario 


Evacuation  by  air  -  7  days 


Yellow:  Evacuees 
in  East  Timor 

Blue:  Evacuees 
in  transit 

Evacuees 
in  Darwin 
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East  Timor  evacuation  scenario 


Yellow:  Evacuees 
in  East  Timor 

Blue:  Evacuees 
in  transit 

Evacuees 
in  Darwin 

-  Shortage  of  ground  escorts  -  22  days 

in  —i 


Base  case  -  7  days 
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East  Timor  evacuation  scenario 


-  Logistics  requirements  can  also  be  investigated. 
For  example,  evacuation  by  sea  requires  greater 
fuel  supplies  in  Dili: 


DIESO  Quantitie 
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Questions 


